Less than a decade ago most people carried only one Wi-Fi enabled device—a Wi-Fi enabled laptop. Since then, what is often referred to as the Wi-Fi revolution has taken the world by a storm. According to Wi-Fi Alliance, there were approximately 1.1 Billion Wi-Fi enabled devices shipped in 2012 alone. With the proliferation of Wi-Fi enabled smartphones, tablets, gaming consoles, and embedded household appliances like TVs, an average household has more than five Wi-Fi enabled devices at any given time. Wi-Fi devices support a number of vertical applications like health, fitness, smart energy, and internet of things (IoT). These and other applications are anticipated to drive the total amount of Wi-Fi shipments per year to double to 2.2 Billion in 2016. One universal Wi-Fi spectrum and the rapid standardization and adoption cycle of Wi-Fi technologies such as 802.11 a/b/g/n and soon 802.11 u and 802.11 ac has made Wi-Fi the broadband wireless access of choice.
In parallel, cloud computing and associated cloud technologies are creating an information technology (IT) revolution of their own. The adoption of cloud technology was possible due to cheap long haul transmission capacity (often referred to as “fat pipes”), and the low cost of compute cycles and storage. Leveraging this trend, Wi-Fi and cloud technologies combined are expected to usher in a new era of ubiquitous networking and service availability.
The first generation Wi-Fi access points (APs) were standalone APs such as those provided by Linksys, Netgear, etc. Such APs are often referred to as autonomous, independent, or fat APs. Such access points typically have a complete IP router function that includes a local Dynamic Host Configuration Protocol (DHCP) server, a basic network address translation (NAT) port, support for popular port triggering protocols (e.g., such as Universal Plug and Play (UPnP) protocols, and NAT port mapping protocol (PMP)), and a domain name system (DNS) server. Some of these Wi-Fi access points include basic access control functions (ACL) like media access control (MAC) filtering and time of the day-based internet access restrictions.
However, such first generation standalone APs must typically be configured individually. Therefore, to deploy multiple standalone APs (which is becoming the norm), a network administrator must log into and configure each Wi-Fi AP independently, making configuration changes a tedious and error-prone process. In addition, standalone APs make it difficult for the user to monitor the wireless network in a centralized manner; obtaining statistics such as aggregated bandwidth statistics, usage data, and/or status information across all of the APs in the network must be done manually. Further, to configure the AP the network administrator often needed to be familiar with IP networking and the configuration options for the AP that were made available through a graphical user interface (GUI) provided by an embedded web server in the AP. Additionally, broadband service providers often cannot provide any value added device management services because the Wi-Fi home access point NATs all the IP traffic and hides all device visibility.
Campuses and large enterprise applications often require the management of multiple APs (e.g., 10s to a few 100 access points). Standalone APs were fast becoming impossible to manage in any scale, so companies began to move to a hierarchical architecture for centralized monitoring and configuration of APs. Some such architectures included a Wireless Access Controller designed to scale to a few hundred APs. The interface between the AP and controller was proprietary and loosely based on the Control and Provisioning of Wireless Access Points (CAPWAP) protocol (e.g., specified in RFC 5415). The Wi-Fi access and the IP router functions of the standalone AP were split between the dependent AP and the Wireless Access Controller. Since the interface between the controller and AP was vendor specific, the split functionality varied between vendors. Other architectures can also include an AP architecture where certain functions of the Wi-Fi MAC were split between the APs and the controller (often referred to as a “split MAC architecture”). This architecture can allow the controller to perform centralized radio frequency (RF) management of APs for interference mitigation and coordination.
However, such controllers operate at Layer 3 (or higher) and provide centralized management and configuration of the IP control plane, the traffic/forwarding plane, and RF management. This configuration (e.g., typically implemented on a 1RU or 2RU servers) can severely limit the scalability of such a solution to a few hundred APs, which is not suitable for the massive scale of outdoor and residential applications. For example, tens of thousands of Wireless Access Controllers would need to be deployed to support millions of concurrently active devices. Such a solution would be nearly impossible to manage and would be cost prohibitive since Wireless Access Controllers are very expensive. Further, the Wireless Access Controller is a single point of failure, so if a WLAN controller fails then all of the APs connected to that controller will also fail. Dual-redundant controllers, while technically possible, are often cost prohibitive. And like first generation APs, device management and device centric value added services can't be provided because the controller hides the topology and the devices that the controller manages.